POS efficient l1 polling #2506
POS efficient l1 polling #2506
Conversation
Closes ##2491 Begin to add chunked fetching of stake table events.
* try to get tables in `get_stake_tables` * if not available get events from contract
And some cleanup
And have it return `Option`
Pass fetch_stake_tables test
| state.snapshot.head | ||
| }; | ||
| while let Some(event) = events.next().await { | ||
| let L1Event::NewHead { head } = event else { |
There was a problem hiding this comment.
This is the latest L1 block (that may not be finalized yet). We should only consider finalized blocks for the stake table because otherwise the stake table may change on L1 after we fetched it.
|
|
||
| /// Divide the range `start..=end` into chunks of size | ||
| /// `events_max_block_range`. | ||
| fn chunky2(start: u64, end: u64, chunk_size: usize) -> Vec<(u64, u64)> { |
There was a problem hiding this comment.
How about returning a Range instead of (u64, u64)?
|
Need to check if the limit settings we have right now make sense. Or if we should switch to using subscriptions. For alchemy the limits are documented here: https://docs.alchemy.com/reference/eth-getlogs |
|
I think for subscriptions there is no way to subscribe to only finalized L1 events. I might be wrong about this but couldn't find it. So we would have to do some extra work to make sure we don't consider anything that isn't finalized. If we use HTTP then I think it should be possible handle the errors we get when we fetch to many events and fetch less. For that I think we can check what HTTP errors are returned from alchemy and infura (we use both providers at the moment) and handle those. |
|
Hmm, both seem to return HTTP 200 for too large requests, and not the same error code infura alchemy So I wonder if we should try like 5 more times with smaller request sizes as long as we do get a successful response from the RPC and then give up, because it's then likely not the response size that is the problem. |
Closes ##2491
This PR:
Asynchronously updates stake table cache by listening for
L1Event::NewHead. This happens in a second update loop thread (added toL1Client.update_tasks). On each such event, stake table events starting atL1State.snapshot.headand ending on the block received in theNewHeadevent. This should be safe sinceL1State.snapshot.headin initialized to 0. So the first such event will be a large update from block0to currenthead. Following updates will be small.